Most people now have a collection of small plastic cards, representing various credit cards, store cards, identity cards, membership cards, and so on. Information about the card and its owner, such as account details and so on, is normally printed or embossed on the card, and may also be stored in some form of magnetic strip. Note that such cards are simply passive storage devices, and the information that they contain is fixed at card creation time.
In recent years, smart cards have also proliferated. These are similar in scale to traditional credit cards, but incorporate within their plastic cases a microelectronic memory and also (optionally) an embedded processor. It will be appreciated that the computational resources available within a smart card are extremely limited compared to those of a desktop workstation, or even a laptop or handheld device. One especially popular form of smart card is known as a Java Card. This is based on the Java platform developed by Sun Microsystems (“Java” and “Java Card” are trademarks of Sun Microsystems Inc). In such devices, a Java virtual machine (VM) is provided within the smart card to allow the execution of Java applets or applications. Particular advantages of being able to use the Java environment for smart card applications are the inherent security features of the Java environment, plus the ready availability of software development packages for the Java programming language. It is estimated that by the end of 2002 over 200 million Java cards had been shipped. More information about the Java Card smart card platform is available from the page: /products/javacard/ at the web site: http://java.sun.com and from the site: http://wwwjavacardforum.org/, and also from the book: “Java Card Technology for Smart Cards” by Zhiqun Chen, Addison-Wesley, 2000, ISBN 0-201-70329-7.
An Application Programming Interface (API) is defined for the Java Card platform. Applications written in the Java programming language invoke this API to access the Java Card run-time environment (JRE) and any native services. The Java Card API allows application portability, in that the same application can run on any smart card that supports the API. The Java Card API is compatible with international standards, in particular the ISO/IEC 7816 family of standards.
In the desktop environment, there is a clear distinction between a Java applet and a Java application, in particular the absence of a ma in class from the former. Although there is a similar distinction in the smart card environment, applets for use on a Java card platform are not the same as applets that run on a web browser. Programs that run on smart cards may be referred to as either an application or as an applet (the former term will be used generally herein).
The Java Card platform supports multiple applications on a single card. These applications may be separated by firewalls, in order to ensure that they do not interfere with one another. This is particularly of concern if the various applications are operated by different organisations, whose business relationships with the card holder may be independent of one another.
FIG. 1 is a schematic diagram representing the life cycle of a smart card, which in this particular implementation is a Java Card. The life cycle commences with the manufacture of the card, and the initial loading of the base operating system and the Java Card environment (210). Also at this stage, one or more applications may be preloaded (215). Generally, the base operating system and Java Card environment, and also potentially any preloaded applications, may be stored in ROM on the smart card as part of the manufacturing process.
The card is now ready for issue to a card holder (220), which typically involves an appropriate personalisation process, as well as initialisation of the Java environment, and starting the Java virtual machine on the card. The card holder is thereafter able to use the card (230). Note that if the card was originally issued without any preloaded applications, then the card holder may have to load an application prior to making substantive use of the card. In practice however, this situation is rather uncommon, since usually there is at least one preloaded application in order to motivate issuance of the card in the first place.
During the operational lifetime of the card, further application programs may potentially be installed onto the card (235), for example if the card holder signs up to new accounts or services. Conversely, applications may be removed from the card, perhaps because an account is closed.
The last operation shown in FIG. 1 is where the card is terminated (240). This may occur, for example, because the card has a built-in expiry date or is surrendered by the user (perhaps if the user is moving to a new card issuer, or the card is physically damaged).
FIG. 2 is a high-level schematic diagram illustrating the main architectural components in a typical smart card application. Thus smart card 102 belongs to card holder 101. Note that smart card 102 may be used as a standalone device, or may be incorporated into some larger system such as a mobile phone. Smart card 102 interacts with a terminal 110 by exchanging an application protocol data unit (ADPU) 108. The format for the ADPU is defined by the International Standard ISO/IEC 7816-3 and typically comprises a command header portion and a payload portion.
Terminal 110 may be a handheld device, an adjunct to a desktop workstation, a dedicated card reader (analogous to an ATM) or any other suitable system. Communications between the smart card 102 and the terminal 110 may be by wired connection or by wireless link (e.g. radio or some other electromagnetic signal), depending on the particular devices concerned. Terminal 110 may be under the direct control of an operator 111 (such as for a handheld terminal), or alternatively terminal 110 may be automated (such as for an ATM). In this latter situation, the card holder 101 may operate the terminal 110 himself/herself.
Terminal 110 interacts with a back office 130 over any suitable form of network 120, such as the Internet, a local area network (LAN), a wide area network (WAN), and so on. Back office 130 may comprise multiple systems (not explicitly shown in FIG. 1), such as a web server or portal attached to network 120, perhaps with an application server and/or a database system behind. Note that the terminal 110 may be off-line until activated by a smart card 102, a card holder 101 or a terminal operator 111 to access a back office 130 over network 120.
It will also be appreciated that in some situations, terminal 110 may interact with card 102 without reference to any other system (such as back office 130). For example, terminal 110 might be some form of machine, such as a car or a photocopier, and card 102 might be used to control access to the machine.
In operation, the card holder 101 typically places the card 102 into or adjacent the terminal 110, thereby allowing the two to interact, e.g. to perform a debit operation from the card to purchase some goods. This interaction will generally be referred to herein as a session, and normally involves the exchange of multiple messages between the smart card 102 and the terminal 110.
Associated with each applet on smart card 102 is an Application Identifier (AID). The AID is a byte string up to 16 bytes long, whose format is defined by International Standard ISO/IEC 7816-4:2004. According to this standard, the first 5 bytes or octets of the AID represent the registered application provider identifier (RID) and have a value allocated by ISO or one of its member bodies. The RID indicates the merchant or other entity involved with operating the application, hereinafter referred to as the RID operator. The RID operator is generally responsible for the back office system 130, and is depicted as application/RID operator 131 in FIG. 2. The last 11 bytes of the AID constitute the proprietary application identifier extension (PIX). The PIX is determined by the RID operator 131, and can be used to store a reference number or other information associated with the application.
International standard ISO/IEC 7816-4 defines a procedure, namely the Select command, to allow a terminal to specify and launch a desired application on a smart card; selecting an application determines the start of a session. The processing associated with the Select command is illustrated at a high level in the flowchart of FIG. 2A. The processing starts when the smart card 102 is first inserted into the terminal 110. The terminal detects the insertion of the smart card (162), and in response to such detection activates the smart card (164, 172). This activation generally includes providing power to the smart card and launching a default application on the card. The default application is so-called because it is automatically started when the card is reset, such as on power up. In some implementations, the default application is identified as the applet that was most recently running on the card (prior to the reset). In other implementations, the default application may be a fixed applet.
The terminal now determines an application on the card to launch (165), and sends a corresponding Select command using an ADPU 108 to the smart card (166). The ADPU specifies the AID of the selected application for use in this session. The request from the terminal is received by the smart card (174). The request is handled by an applet selector program that is running on the smart card 102 as part of a card executive layer. The applet selector is responsible for locating the application that matches the AID requested from the terminal, i.e. the application that has the same AID as that specified in the request (176). If a matching application is found, then this application on the smart card is duly launched (177). The smart card now returns to the terminal 110 an indication of whether or not the requested application has been successfully launched (179 and 180). (N.B. This last action is optional within the context of ISO/IEC 7816-4, although it is commonly implemented).
FIG. 2B describes a variation on the processing of FIG. 2A (also in accordance with ISO/IEC 7816-4). The operations in FIG. 2B are the same as described above in relation to FIG. 2A until operation 166, in which the terminal 110 supplies the card with an abbreviated or truncated AID (known as a partial AID). For example, the partial AID may comprise the first ten bytes of an AID. In these circumstances, there may be multiple matches against the partial AID. For example, if two applications have AIDs that have their first ten bytes in common and then differ only in the final six bytes of the AID, they will both match the same partial AID of length 10 bytes (or less). One reason for using a partial AID might be if the terminal 110 wants to identify all applications on the card having a particular RID.
Consequently, at operation 176A (corresponding to operation 176 in FIG. 2A), the smart card identifies one of the potentially multiple matching applications on the card. This application identified at operation 176A represents the first matching application. The (first) matching application (if any) on the smart card is now launched (177), and a response is provided to the terminal (179A, 180) indicating whether or not the partial AID request (176) was successful. If this request was successful, then the response 179A also includes the AID of the application that was launched at operation 177. If this AID corresponds to the application desired by the terminal (183), then session processing continues (185). However, if the launched application as indicated by the received AID is not the desired application, then processing at the terminal loops back to operation 166, whereby another request containing the partial AID is sent by the terminal to the smart card 102.
The smart card now identifies at operation 176A the next application that matches the partial AID, launches this next matched application (177), and returns the full AID for this next matched application (179A). In addition, the previously launched application (i.e. the first application) may be terminated (not shown in FIG. 2B). The terminal again tests at operation 183 to determine whether or not the matching application corresponds to the desired application, and if not, then we proceed once again around the above loop.
The procedure of FIG. 2B therefore terminates either when the desired application on smart card 102 has been launched, thereby allowing the session to continue (185), or there are no more applications on smart card 102 that match the partial AID. In other words, the AIDs for all the matching applications (if any) have already been returned one-by-one at operation 179A, and then rejected at operation 183. In this latter case, the smart card fails to find any further matching applications (i.e. the test of operation 176A is negative), and returns a failure indication to the terminal at operation 179A. The terminal then detects that no (further) application has been launched on the card (182), and so aborts the session (184).
Note that to support the above processing, the card 102 needs to ensure that it selects a different matching AID each time it loops through operation 176A (otherwise it may return a matching AID that has already been rejected by the terminal). One mechanism to ensure this is for the smart card to maintain a list of those matching AIDs that have already been returned to the terminal at any previous loops through operation 179A. Alternatively, the smart card may recognise some ordering of the AIDs (for example, based on the binary value of an AID). In this latter case, the smart card notes the matching AID sent last time at operation 179A, and for the next loop through operation 176A selects the next matching AID in the imposed ordering.
It has been suggested that a smart card may include a facility to provide a complete list in a canonical order of all the applications installed on the smart card. (This suggestion is described in a submission by the Netherlands to the standards committee JTC1/SC17 of the ISO/IEC). Each application on a smart card is represented in the list by its AID. The list could then to be used in all presentations by the card of its applications, for example as a directory file. It is also contemplated that the canonically ordered AID list could be used in a variation on the Select command as depicted in FIGS. 2A and 2B. In particular, an index to the list could be encoded over one octet, for instance using values 1 to 253, with the applications specified in the order in which they were originally loaded onto the smart card. This would then allow a desired application to be specified for selection by index value (rather than by AID).
According to this proposal, which is especially relevant to a Java Card implementation, three particular applications are distinguished:                (1) a card management application—this performs functions related to the loading, initialization and removal of other applications.        (2) a card holder personal data application—this typically contains data and functions related to the card holder, such as a user profile, a PIN, biometrics, and name and address. These functions and data may be accessible in the card by other applications as appropriate.        (3) the default application—discussed above. (Note that a card that supports multiple modes of communication with terminal 110 may have a different default application associated with each particular mode of communication).The card management application and the card holder data application are generally preloaded onto a smart card (see operation 215 in FIG. 1).        
In the proposal, the three special applications listed above are assigned predetermined index values. In particular, the index value 0 is reserved for the current default application; the index value −2 (254) is reserved for the card holder data application; and the index value −1 (255) is reserved for the card management application. Note that the card holder data application and the card management application will therefore generally appear twice in the list, once at the position in the list that reflects when they were loaded, and once at their reserved location (i.e. −2 and −1 respectively). This submission has not yet been formally adopted by the ISO/IEC.
Most early smart cards were viewed primarily as memory devices. The main purpose of a session involving the card was therefore to read data to or write data from a selected location on the card. The development of Java cards has introduced an application-oriented environment, in which the behaviour of a card is controlled by an application on the card. This has led to the role of a default application as mentioned above to take initial control of a card, pending user selection of a particular desired application. A further submission by the Netherlands to the standards committee JTC1/SC17 of the ISO/IEC has suggested that a default application should firstly be able to provide a list of applications on the smart card and secondly to support selecting an application on the card to run.
Although the Java Card environment supports multiple applications from different RID operators, in practice, a large majority of issued cards originate from and are run by a single RID operator. In other words, applications from one RID operator are typically found on one card, and applications from another RID operator are found on a different card. Moreover, many cards are provided with only a single application. Consequently, relatively little attention has been paid to the handling of smart cards having multiple applications, potentially from a range of different vendors (i.e. from different RID operators).